Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for Active Job #670

Merged
merged 7 commits into from
Aug 5, 2021
Merged

Add support for Active Job #670

merged 7 commits into from
Aug 5, 2021

Conversation

imjoehaines
Copy link
Contributor

Goal

This PR adds support for Active Job when not using an existing integration. For example, nothing will change when using Sidekiq as the backend but we can now track exceptions in Active Job's async backend

We capture the following metadata automatically for both handled and unhandled exceptions (note some data is not available on certain Rails versions):

  • job_id
  • job_name
  • queue
  • locale
  • arguments
  • provider_job_id (added in Rails 5)
  • executions (added in Rails 5)
  • timezone (added in Rails 6)
  • enqueued_at (added in Rails 6)

The context is set to the job name and queue to match other queue integrations, e.g. ExampleJob@some_queue, and the default app type is set to "active job"

Testing

Maze Runner tests run against Rails 4, 5 & 6 with a variety of Ruby versions

@imjoehaines imjoehaines merged commit 98cef22 into next Aug 5, 2021
@imjoehaines imjoehaines deleted the active-job-support branch August 5, 2021 16:35
@imjoehaines imjoehaines mentioned this pull request Aug 10, 2021
@knu
Copy link

knu commented Aug 20, 2021

Hi,

After this change, exceptions handled by discard_on seem to get notified. Is that intentional? I'd expect discarded exceptions not to be reported.

@imjoehaines
Copy link
Contributor Author

After this change, exceptions handled by discard_on seem to get notified. Is that intentional? I'd expect discarded exceptions not to be reported.

Yes, this is expected as there isn't an API to detect if an error would be discarded. An error being discarded also doesn't necessarily mean it's unimportant to know about, since errors that would make a job impossible to finish will often end up being discarded to prevent retries that will never succeed

If you have errors that you don't want to end up in Bugsnag, you can use the discard_classes option to discard an error by name. If the logic needs to be more complicated then you can use an on error callback instead. For example, to ignore a specific combination of error and job:

Bugsnag.configure do |config|
  config.add_on_error(proc do |report|
    next if report.exceptions.empty?
    next if report.meta_data[:active_job].nil?

    error_class = report.exceptions.first[:errorClass]
    job_name = report.meta_data[:active_job][:job_name]

    if error_class == 'ClassToIgnore' && job_name == 'JobToIgnore'
      false # ignore the report
    end
  end)
end

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants